Skip to content

feat(llm): env var to force/disable Responses API for OpenAI/Azure#15

Merged
ngoclam9415 merged 1 commit into
developfrom
feat/responses-api-env-toggle
Jun 8, 2026
Merged

feat(llm): env var to force/disable Responses API for OpenAI/Azure#15
ngoclam9415 merged 1 commit into
developfrom
feat/responses-api-env-toggle

Conversation

@ngoclam9415

Copy link
Copy Markdown
Contributor

Summary

Adds an environment-variable override to force or disable the OpenAI Responses API per provider — no config.json edit required.

Env var Scope Values
OPENAI_USE_RESPONSES_API OpenAI direct 1/true/on/yes0/false/off/no
AZURE_USE_RESPONSES_API Azure same
LLM_USE_RESPONSES_API generic fallback (any provider) same

Resolution precedence (_should_use_responses_api)

provider env var > LLM_USE_RESPONSES_API > use_responses_api config flag > model-prefix auto-detect

Mirrors the existing *_THINKING_EFFORT env pattern. Resolved at call time, so changes take effect without a process restart.

Behavior / trade-offs

  • Explicit override bypasses the capability gate — same semantics as the existing use_responses_api config flag (operator takes responsibility). Forcing on against an unsupported endpoint (e.g. Azure api-version < 2025-03-01) emits a logger.warning so the likely 400 is debuggable rather than silent. Bump AZURE_OPENAI_API_VERSION to 2025-03-01-preview+ to use it on Azure.
  • Invalid values (e.g. maybe) are logged and ignored, falling through to auto-detect.
  • Falsy override forces gpt-5/o3/o4 models off the Responses API without touching config.
  • Moonshot inherits only the generic LLM_USE_RESPONSES_API (scoped to OpenAI/Azure per request).

Files

  • dana/common/llm/providers/openai_compatible_base.py_resolve_use_responses_api_env(), _RESPONSES_API_ENV_VAR attr, updated precedence + warning
  • dana/common/llm/providers/{openai,azure}.py — wired provider env var names
  • tests/unit/llm/test_responses_api_routing.py — 9 new cases

Testing

  • test_responses_api_routing.py: 40 passed
  • Adjacent provider suites (openai/azure streaming, chat_via_responses, reasoning_items_capture): 62 passed

Add OPENAI_USE_RESPONSES_API / AZURE_USE_RESPONSES_API (plus generic
LLM_USE_RESPONSES_API fallback) to override Responses API routing without
editing config.json.

Precedence: provider env > generic env > use_responses_api config flag >
model-prefix auto-detect. Resolved at call time so changes apply without
restart. Explicit override bypasses the endpoint capability gate (mirrors
config-flag semantics); warns when forced on against an unsupported
endpoint (e.g. Azure api-version < 2025-03-01). Invalid values logged and
ignored, falling through to auto-detect.
@ngoclam9415 ngoclam9415 merged commit 105207f into develop Jun 8, 2026
1 check failed
@ngoclam9415 ngoclam9415 deleted the feat/responses-api-env-toggle branch June 8, 2026 07:18
ngoclam9415 added a commit that referenced this pull request Jul 7, 2026
Two unrelated groups, both pre-existing on develop:

1. tests/unit/core/test_inject_llm_provider.py (3 failures)
   Tests pass llm_provider="openai"/"anthropic" (string) which eagerly builds
   a real provider requiring OPENAI_API_KEY/ANTHROPIC_API_KEY. They only check
   identity wiring and never call the LLM. Add an autouse fixture that supplies
   dummy env keys so construction succeeds offline.

2. tests/unit/test_llm_providers.py::TestOpenAIReasoningTokens (3 failures)
   Thinking models (gpt-5*) route through the Responses API since #9/#15, but
   these tests still mocked client.chat.completions.create — so the awaited
   call hit an un-mocked MagicMock ("can't be awaited"). Rewrite to mock
   client.responses.create with a Responses-API-shaped response (output items
   + usage.output_tokens_details.reasoning_tokens) via a shared helper.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant